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Motivation  -  Situationai  Awareness 


First  responders  and  others  operating  in  the  “last  mile”  of  crisis  and 
hostile  environments  are  already  making  use  of  handheld  mobile 
devices  in  the  field  to  support  their  missions. 


Rapid  Incorporation  of  New  Data  Sources 

•  Many  data  sources  (real-time,  historical,  ...) 

•  Data  is  fragmented  across  different  apps  on  the  mobile  device 
Minimized  Information  Overload 

•  Edge  users  are  under  high  cognitive  load 

•  Information  required  is  a  function  of  user’s  context  and  therefore  dynamic 
Simple  Use 

•  Users  are  under  high  stress 

•  Small  screen  devices 

Resource  Constrained  Hostile  Environment 
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Hostile  Environments  Characteristics 


Wimpy  edge  nodes 

•  Limited  resources  (CPU,  battery  and  memory)  on  mobile  nodes 

•  Example:  Expensive  computations  on  a  smartphone  may  drain  the  battery  fast 
Limited  or  no  end-to-end  network  connectivity 

•  Implicit  assumption  of  WAN  connectivity  is  not  always  valid 

•  Example:  No  access  to  internet  during  a  disaster,  DoS  attack 
High  cognitive  load 

•  Application  latency  and  fidelity  become  important 

•  Example:  A  slow  application  will  increase  the  cognitive  load  on  the  user 
Bounded  elasticity 

•  Upper  bound  on  number  of  consumers  known  in  advance 

•  Example:  Fixed  number  of  first  responders  in  a  location 
Dynamic  environment 

•  Static  deployment  topologies  cannot  be  assumed;  Survivability  essential 

•  Example:  An  automobile  with  a  server  may  not  be  available 
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Context  Diagram 
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Architecturally  Significant  Requirements 

Extensibility 

•  Add  new  data  source  quickly  with  minimal  impact  on  existing  sources 
Runtime  Configurability 

•  Make  data  sources  user  configurable  (e.g.,  using  data  filters)  at  runtime 
Performance 

•  Minimize  network  bandwidth  usage  of  the  tactical  network 
Energy  Efficiency 

•  Optimize  energy  consumption  on  mobile  handheld  devices 
Usability 

•  Provide  a  responsive  and  unified  user  interface 
Availability 

•  Support  intermediate  disconnections  with  remote  data  sources 
Security 

•  Support  existing  security  protocols  and  provide  transport  layer  security 
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Request  Response  Interaction 
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Publish  Subscribe  Interaction 
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Example  Routes 
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Extensibility  -  Adding  New  Data  Sources 


Problem  •  New  data  sources  are  available  in  the  field 

•  Adding  and  validating  them  is  time  consuming 

Assumptions  •  The  data  source  has  a  remote  API 

•  The  data  format  is  defined  and  stable 

Solution  •  Minimize  coupling  between  data  sources  by 

encapsulating  each  data  source 

•  Implement  common  connectors 
(request/response  and  publish  subscribe) 

Future  extensions  Automate  common  tactical  integration  patterns  to 

provide  an  end-user  programing  interface 
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Data  Model 


Data  model  is  represented  as  objects  (POJOs)  shared  between  clients 
and  server 

Data  model  changes  must  be  synchronized  between  clients  and  servers 

•  Our  assumption:  data  model  is  “relatively”  stable 
Data  model  can  be  created  in  the  following  ways 

•  Manual  definition  -  works  best  in  case  of  a  simple  data  model 

•  Code  generation  -  WSDL2Java  to  generate  code 

•  Reuse  existing  iibrary  -  Twitter4J  is  an  existing  Java  implementation  of 
Twitter  API 
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Mashup  Mechanism 


Merging  data  across  data  models  is  a  mechanism  to  relate  data  across 
models. 

•  Example:  foreign  keys  in  a  relational  database 

In  eMontage,  we  assume  a  large  proportion  of  situational  awareness 
data  has  some  form  of  geo-location  associated  with  it 

•  use  geo-location  as  the  common  key 

All  data  is  currently  mashed  up  on  a  map-based  interface. 

•  as  long  as  two  data  elements  from  different  data  sources  are  referenced  by 
geo-location  (latitude  and  longitude),  they  will  always  be  displayed  correctly 
on  a  map 

•  the  actual  relating  of  information  will  happen  with  the  user 
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Example  Data  Sources 
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Configurability-  User-defined  Runtime  Filtering 


Problem 

Assumption 


Solution 


Future  extensions 


Information  overload 


The  user  knows  what  information  they  need  in  a 
particular  context  (e.g.,  location,  keywords,  date 
ranges) 

Provide  mechanisms  that  allow  users  to  reduce  the 
volume  of  information 
•  using  rule-based  filtering  at  runtime 


Provide  “data  discovery”  mechanisms  (e.g., 
visualizations,  clusters,  outliers)  when  the  user 
does  not  know  what  information  they  need 
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Usability  -  Unified  User  Interface 


Problem 

Data  is  fragmented  across  multiple  applications 
and  databases 

Assumption 

•  Data  is  geo-coded 

•  A  unified  view  provides  more  value  compared  to 
isolated  views  of  data  from  different  sources 

Solution 

Mashup  of  geo-code  data  viewed  on  a  map  allows 
visual  unification  of  data 

Future  extensions 

•  Provide  other  non-map  based  visualizations 

•  Provide  data  join  mechanisms 

Performance  -  Minimized  Bandwidth  Utiiization 


Problem 

Bandwidth  is  a  scare  resource  at  the  “last  mile”  of 
edge 

Assumption 

Possible  to  have  an  intermediary  node  in  the 
network 

Solution 

Add  an  intermediary  node 

•  Use  filtering  at  the  source  (only  send  information 
is  required  by  the  mobile  nodes) 

•  Transform  to  a  more  bandwidth  optimized  format 
(e.g.,  XML  to  JSON/Protocol  Buffer) 

Future  extensions 

Use  protocol  transformation  (use  a  SPDY  instead 
of  HTTP) 
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Power  Consumption  -  Offloading  Expensive 
Computation 


Problem 

Mobile  nodes  have  limited  resources  (CPU,  battery 
and  memory) 

Assumption 

Possible  to  have  an  intermediary  node  in  the 
network 

Solution 

Perform  expensive  computation  (e.g.,  XML  parsing, 
multiple  network  calls)  on  a  proximate,  relatively 
resource  rich  node 

Future  extensions 

Use  multi-node  cloudlets  to  increase  performance 
and  fault  tolerance 

Availability  -  Disconnected  Operations 


Problem 

Assumption 

Solution 

Future  extensions 


Edge  nodes  may  have  to  work  in  disconnected  or 
semi-connected  mode  (from  enterprise/TOC 
network) 

•  Possible  to  deploy  a  resource-rich  node  locally 
(e.g.,  on  an  automobile) 

•  Real-time  data  is  generated  locally 

•  Possible  to  know  in  advance  what  data  will  be 
required  fora  mission  (e.g.,  maps  by  locations) 

Localize  and  cache  data  sources  on  a  cloudlet. 

Use  persistent  distributed  caching. 

Adaptive  pre-fetching  to  support  intermittent 
disconnections 
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Architectural  Alternatives 


Native  Mobile  Client  Only 

•  A  native,  mobile  client  app  directly  connected  to  backend  data  sources 
Mobile  Browser-Server 

•  A  mobile  browser  client  to  a  server  that  acts  as  an  intermediary  between 
the  mobile  client  and  the  backend  data  sources 

Native  Mobile  Client-Server 

•  A  native,  mobile  client  app  connected  to  an  in  intermediary  server 
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Architectural  Alternatives 
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Current  and  Future  Work 


More  intuitive  user  interface 

•  Support  other  views  of  data 

•  Provide  data  exploration  and  discovery  capabilities 
Focus  on  performance 

•  Use  caching 

•  Allow  use  of  multiple  processors/cores  when  possible 
Add  security  mechanisms 

•  Use  with  Wave  Relay  radios 

•  Add  transport  and  message  level  encryption 
Integrate  with  edge  analytics 

•  Build  edge  analytics  techniques  on  top  of  current  eMontage  implementation 
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